In an attempt to locate a database program that will serve my immediate needs but also contains some room for growth, Reflex appeared to be a candidate based upon brief comparisons I have seen in various magazines. This fact caused me to agree to revie
w the program and thus have the opportunity to evaluate its practicality for filing my wife's music collection. My previous direct experience with filing programs consists of briefly using PFS File on my Apple II+ a few years ago. Therefore, the proce
ss of reviewing Reflex is a harsh test of the program's friendliness and of the documentation quality.
Reflex is a "relational" database. Not being familiar with this term I tried to find a definition, but discovered that it is demonstrated through examples in the second section of the documentation rather than defined in a few simple words. We will th
erefore talk more about this later and attempt to give some indication of when it is most useful. Being able to choose whether or not to "link" the files allows Reflex to conveniently be used for simple filing jobs where the relational feature is ignor
ed, or to be used for sophisticated database applications by employing the relational feature. The package consists of two disks (a program disk and a help/examples disk) and a 327 page book. The disks are not protected and the user is instructed to make
backup working copies.
A Database is made up of one or more files. Each file is made up of individual records (e.g. a sheet of paper with specific information). Each record is made up of one or more fields (which are the smallest units of data entry). When a file or databas
e is being designed, each field is given a name which is eventually used in the searching process during recovery of information from the database. The field names in Reflex can be up to 32 characters long, the field lengths can be up to 1002 bytes, a r
ecord can contain up to 254 fields, and the record can be up to 1008 bytes long (which is approximately one single-spaced typewritten page). The number of records per file is limited only by disk capacity and can in fact be extended over several disks.
Additionally, Reflex contains a lot of other features for both convenience and necessity. For example, it has many built-in functions much like a spreadsheet so that the generated report can contain numbers that have been calculated using information
retrieved from the files. It automatically saves your work after about two minutes if it detects no activity, except if you are altering the format of a record template, in which case you must manually initiate a save. Text, numbers, dates, and times c
an be entered into the fields.
A person with experience using other database programs would probably jump in at Section Three: DETAILS AND TECHNIQUES. However, I started at the beginning and systematically worked through the examples in Section One: SINGLE FILES and Section Two: M
ULTIPLE FILES. The text is clear and contains specific instructions on how to make each entry and can be easily followed even if a person is not completly familiar with the Macintosh. It also has a lot of pictures which helps give the illusion of rapid
learning progress and also greatly assists in going back to locate and review particular procedures. I found that the documentation anticipated many of my questions. Creating a file is very straight forward and takes advantage of the Macintosh with use
ful Menus and graphics. The file is named in a dialog box and naming the fields consists of listing one after another in the database Overview Window.
The format of the data entry form, however, can be designed to suit your eye and the nature of the data to be entered using only the mouse except for typing the actual field names. This is important because this form is used to fill each record that goe
s into the file. The fields can be moved about and sized and various fonts can be used. I quickly felt at home with the process. After the file has been created and data entered into the file, the record design can still be changed with no bad effects
if fields are added and minimum damage if fields are removed (a rather unlikely circumstance), namely loss of the data in the deleted fields. To recover data from the database a report is created by either using the default table format or by designing
your own to display the desired information in whatever format you wish. This report is used for searching, displaying, and printing the recovered data. Examples of single and multiple file databases are included to demonstrate the processes of manipu
lating the files and searching them for the recovery of specific information and information in various formats.
The ability to include links between files combines them into a relational database and this gives much greater power and flexibility in database design. This is best illustrated by a simple example. If we wished to have a database from which we could
recover the names of all Apple Dayton members and all the Macintosh programs they own, a single file system would clearly have shortcomings. For example, if we wanted to have one record for each member, then it would also have to contain a list of all o
f his/her programs. If any member had over 254 programs this system would not be applicable assuming one program per field (ignoring the total record length limitation). It would be inefficient, even if the total number was not a problem, because each
record would have to contain enough fields to accomodate the member with the most programs, so all other records would have unused fields which consume storage space.
A more efficient approach is to have two files, a file with one record per member and another file with one record per program. The two files can then be related by making links between each member's record and the programs owned by her/him and then mak
ing links between each program's record and the members who own that program. If the number of records is even moderately large, the cross linking can be very complicated to visualize or to draw. The process of constructing such a relational database i
s, however, surprisingly straight forward. For example, when constructing a relational database from scratch with the links already defined, the program fills-in the other end of the link as one end is entered. The process can be extended with links ma
de to additional files and it is also quite practical to link files that already exist. The member/program database can be easily searched to yield lists of either who owns a particular program or what programs are owned by each or all members.
In summary, I am very pleased and impressed with the power of Reflex. It is a good buy. Its convience of use and the many nice features that I have not even mentioned, indicates to me that this software is well thought out and is clearly not a "first e
dition". Another indicator that it has been through some bug removal cycles was the absence of a crash or unintentional data loss even with considerable experimentation and some rather illogical actions by me. The major weakness for my needs is a sho
rtage of guidance on how to carry out various searches and how to most effectively use all of the searching tools. In other words the documentation walked me through database construction in great detail, which I needed, but it is not as thorough on data
recovery.
Some examples are given in detail but I could use more cases. A strong knowledge of the searching process will influence the file design, so it is an important component of effective database use. By constructing simple experimental databases and then
trying out all the available functions that are not introduced in the examples, I believe this can eventually be solved or resolved. [Editor - REFLEX was formerly known as INTERLACE]
From Apple-Dayton Journal (Nov 1986), the newsletter of the Apple Dayton Users Group, Dayton, OH. Non-commercial users groups have permission to reprint (with this acknowledgement).
